The present embodiments relate to computer networks and are more particularly directed to a network with distributed authentication control.
Networks have found favor in many applications in the communications industry and for various reasons. For example, Ethernet is a widely used and cost effective medium, with numerous interfaces and speed capability up to the 10+ Gbps range. Ethernet networks may be used in applications that are incorporated at a single location by a single entity such as a company or the like, or the entity as an alternative may couple various local area networks (“LANs”) together to form a larger network, sometimes referred to as a wide area network (“WAN”). Still further, Ethernet technology is also often used to form a network sometimes referred to as a Metro Ethernet Network (“MEN”), which is generally a publicly accessible network that is often affiliated with a metropolitan area—hence, the term “Metro” Ethernet. A MEN provides a so-called Metro domain, typically under the control of a single administrator or manager, such as an Internet Service Provider (“ISP”). A MEN is typically used to connect between an access network and a core network. The access network often includes edge nodes that operate as bridges to private or end users, that is, customer nodes making connectivity to the network. The core network is used to connect to other Metro Ethernet Networks and it provides primarily a frame switching function.
Ethernet networks typically include a number of bridges. A bridge typically operates to receive a block of data referred to as a frame, which is sometimes referred to by other names such as a packet or message and which in any event includes a portion, such as a header, with both a source and destination address. The frame may include other information, such as a payload or data that is being communicated from the device at the source address to the device at the destination address. The bridge receives this frame at a port and may forward the frame based on the frame's destination address and via a port to that destination, where both the source and the destination may be another bridge or a user or other node in the Ethernet network.
Another function of a bridge is to perform authentication, sometimes in combination with a network server that is either directly connected to the bridges or logically accessible by the bridge through one or more additional bridges. In this context, IEEE 802.1X provides port access control for Ethernet and in this regard there is an Extensible Authentication Protocol (“EAP”). EAP provides certain functions and a negotiation of a desired EAP authentication method, where there are various different methods. In some of these methods, when a new bridge node link is enabled or connected to an existing bridge node, the authentication process commences, whereby the genuineness of the new connection is verified. Particularly, the existing bridge node to which the new link is connected becomes an authenticator with respect to the new node connected to the bridge, and the new node or the port on that node is a supplicant. The supplicant, in effect, requests to the authenticator an authentication which, if granted, permits the supplicant device to join the trusted network. In response to the supplicant's request, the authenticator communicates with a network server, again either directly if the authenticator is directly connected to the server or logically through one or more bridges that are in the path of the authenticator to the network server. The entirety of this just-described process is sometimes referred to as an authentication session, which commences with the initial request of the supplicant and continues until the supplicant is granted (or denied) authority to join the network. Note that various frames may go back and forth between the supplicant and authenticator to satisfy the rigors of the authentication and, thus, a certain amount of time may be expended before the session is completed by either a grant of authority or a denial of service (“DoS”).
An unfortunate development in the heavy use of networks in contemporary computing has been the efforts of wrongdoers to disrupt the operation of the network or cause unanticipated increases in the use of network resources. In the context of Ethernet networks, one malicious effort has been for a user to connect to a network bridge and then flood the bridge with an unusually large number of authentication requests. This effort may be by connection to a single bridge node, or the wrongdoer may coordinate numerous requests at different bridges and that overlap in time. The mechanism for such an attack may take many forms, such as email, viruses, and remote access by ways of example. In any event, if successful, the network server becomes overburdened and may begin large-scale denial of service, thereby preventing legitimate users from access to the network.
By way of additional background, the prior art includes a few approaches that attempt to reduce the effects of wrongful use of authentication. In one approach, each bridge node has a limit to the number of authentication requests it will accept from a same user at a same port while an authentication session is already opened at that port. In another approach, each bridge node has a limit to the rate at which it will receive authentication requests. Both of these approaches may prove workable in some instances, but in connection with the present preferred embodiments there are noticed that certain drawbacks arise in these approaches. Specifically, the prior art approaches are localized to each bridge. As a result, as one drawback, in a particular attack on the network, the wrongdoer might distribute the number of requests to numerous different bridge nodes. In this case, each such bridge node may not perceive that it is being attacked and thereby forward each such request to the network server. Collectively as these requests reach the server, however, the server may be overwhelmed and be forced to deny service, both to those requests as well as to legitimate requests it is receiving from the same or other bridges during in the overlapping time period. As another drawback, under the prior art approaches, if a bridge detects a number of requests that exceeds its quota and responds with a pushback to the requestor, that requester may itself be another bridge node, and so forth through a number of bridge nodes. Thus, there is delay as the pushback is forced to propagate backward until it reaches the bridge(s) that is connected to the trouble causing requestor.
Given the preceding, improvements may be made to the prior art, as is achieved by the preferred embodiments, which are further detailed below.